Inside a processor, an arithmetic logic unit (ALU) is circuitry that is controlled by lines (called “control lines” or “control bus”) which carry signals whose values control operations performed by the ALU (e.g. arithmetic and/or logic operations, such as a multiply operation or an exclusive OR operation). Specifically, in a processor that is microprogrammed, a controller generates and places on the control lines of the ALU, a list of values of control signals that specify a basic operation (also called “microoperation”) to be performed by the ALU in a single clock cycle. As will be readily apparent, each value of a control signal is placed on a corresponding control line of the ALU. Two examples of microoperations that can be specified to the ALU are: (1) shift data within a register, (2) latch data from an input bus coupled to data memory.
Each microoperation of the type described above is typically identified to the controller of the processor by a microinstruction, which includes multiple fields, e.g. an operand field indicating data to be input to the ALU (also called “read data”), and a control field that determines (directly or indirectly) a list of values of control signals to be applied to the ALU. The control field may be non-encoded in which case the controller places the value of each bit of the control field directly on a corresponding control line of the ALU (e.g. when a bit's value is 1, the corresponding control signal is driven active). Alternatively, the control field can be encoded, whereby a decoder is used to convert an “n” bit value in the control field into a list of “m” values of control signals, each of the “m” values being placed on an appropriate control line of the ALU.
An encoded control field of a microinstruction contains an operational code (hereinafter “microopcode”) which is typically different from the operational code (hereinafter “macroopcode”) in an instruction (called “machine instruction”) of software in binary form to be executed by the processor (also called “end-user software” or “application”). The just-described difference, between a microopcode and a macroopcode may be absent in processors that are not microprogrammed, although each machine instruction thereto also contains an operational code (simply called “opcode”).
Regardless of whether a processor is or is not microprogrammed, a value of an operational code that can be used in a machine instruction is typically associated with a mnemonic, e.g. in an instruction set architecture (ISA). The ISA is normally prepared manually, by a human who designs the processor. A human who develops end-user software to be executed by the processor may use the mnemonics (in the ISA) to write instructions in assembly language, which are then converted into machine instructions by an assembler (using a mapping in the ISA, between mnemonics and values of the operational code). Alternatively, the human developer may write end-user software in a high level language, such as C or Matlab, followed by generation of machine instructions by use of a compiler (also based on the mapping in the ISA).
As the number of values of an operational code that are specified in an ISA increase, the width of the operational code increases. For example, a modern ISA may make available to a developer, numerous complex functions each of which can be performed by issuing a single machine instruction (such as an instruction to perform Huffman coding or to perform an operation on a vector). The inventors of the current patent application note that when end-user software does not use a significant subset of the complex functions (e.g. does not use half of the mnemonics in an ISA), there appears to be no way to reduce the width of the operational code, e.g. because the width of the operational code is fixed by the ISA regardless of which values of the operational code are used or unused. Hence, there appears to be a need for a solution, as follows.